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I. INTRODUCTION 



A. THE ** SOFTWARE CRISIS'* 

In the late sixties it was realized that the importance 
of software was rapidly exceeding that of the hardware on 
which it was implemented. This was manifested by sharply 
escalating software costs while the cost of hardware under- 
went rather dramatic decreases. The reduced cost of compu- 
ters increased the demand for them and hence their numbers 
and the number and variety of applications in which they 
were used also increased. There was a growing demand for the 
ability to convert existing applications software to make it 
executable on the newer, more powerful and less expensive 
hardware. The complexity and size of new applications also 
increased significantly with correspond! ng increases in the 
complexity and size of the software needed to support them. 
This in turn led to a far greater demand for software than 
the existing software industry could supply. Furthermore, 
it became apparent that software was not a "consumable" 
product that was used once or a few times and then dis- 
carded. It was becoming more and more like a large capital 
investment in a physical plant that required maintenance, 
alteration and enhancement throughout its relatively long 
useful life. 
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Un-f ortunatel y , 



it was extremely difficult to make even 



trivial changes to the software of the day in a reliable, 
efficient, and effective manner. This was especially alarm- 
ing since the cost of developing software seemed to grow 
exponentially with its size and complexity. This meant that 
even after making a substantial investment in software to 
support a complex application, the user faced an even 
greater cost in maintaining its continued usefulness. In 
fact, it was found that most of the cost of a software 
system often occurred after it became operational leaving 
fewer and fewer resources available for new software devel- 
opment. It was from such observations and concerns that the 
term "software crisis" was born. 

Unhappily, things have not changed much and so a decade 
and a half later we still speak of being in the midst of a 
"software crisis" even though this immensely popular, but 
inaccurate, description may have done as much to obscure the 
real issues as it has to call attention to the legitimate 
concerns of the industry. 

Often the exact word used to describe an imprecisely 
understood situation is not of paramount importance. How- 
ever, "crisis" usually describes a brief situation which is 
largely beyond the control of those affected and in which 
immediate, short term actions may significantly affect their 
chances for survival. The so-called "software crisis" 
clearly has not been brief and is not beyond the control of 
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those affected since they are also its creators- "We has 
met the enemy, and it is us.", from the comic strip Pogo by 
Walt Kelly accurately describes the current situation- Fur- 
ther, this "crisis" has not threatened the industry's sur- 
vival, and immediate, short term actions, while often help- 
ful, have not significantly reduced or altered the scope of 
the problem. Unfortunately, the perception of the software 
dilemma as a crisis has led to many proposals of limited 
scope, usually dealing with technical issues alone, that 
taken singly have had very little impact. If we are to have 
a more pronounced effect, we must broaden our outlook 
con si derabl y . 

B. SOFTWARE ENGINEERING 

Shortly after the existence of the "software crisis" was 
recognized came the first hint that it wasn’t really a 
crisis but merely an undesirable situation in urgent need 
of amel i orati on . In the early seventies the term "software 
engineering" began to appear in the literature with increas- 
ing frequency. This is significant because it implies a 
recognition of the need for a disciplined, orderly and 
effective way to approach the problem of producing high 
quality software efficiently. Rather than merely responding 
to the more glaring aspects of a "crisis", we can and should 
develop engineering methodologies for the formulation and 
analysis of problems having software solutions and for the 
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specification, design, development, implementation, main- 
tenance, and evolution of practical software systems that 
solve such problems. We also need, of course, to include in 
our methodologies a way of determining when a problem does 
not have a feasible software solution. 

Although the term "software engineering" is now in 
rather common usage, finding a definition of the term is 
surprisingly difficult, even in texts devoted to the sub- 
ject. One particularly extreme example is CRef. ID where 
the page given in the index as containing that author's 
definition is completely blank! Nor is a definition to be 
found elsewhere in the text. However, some definitions can 
be found and we will state and analyze two of them here. 

In CRef. 2D, Boehm presents the following definition: 

Softi^are Engineering" The practical application of 
scientific knowledge in the design and construction of 
computer programs and the associated documentation re- 
quired to develop, operate, and maintain them. 

and in CRef. 3D Jensen and Tonies offer Bauer's definition 
taken from CRef. 4D: 

The establishment and use of sound engineering prin- 
ciples (methods) in order to obtain economically soft- 
ware that is reliable and works on real machines. 
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The first definition has rather little to offer since 
the base of well established "scientific knowledge" in soft- 
ware design and construction is still quite small- However, 
this should not concern us too greatly. Humans were under- 
taking engineering projects of significant size and com- 
ple;<ity, some of which have lasted more than a thousand 
years, long before there was an established base of scien- 
tific knowledge applicable to them. In other words, engi- 
neers have never relied on scientific knowledge alone or 
waited for scientific advances before attacking pressing 
problems. Experience, ingenuity, and just plain trial-and— 
error have long been hallmarks of the engineering 
prof essi on . 

The second definition may have more to offer. In the 
words of Jensen and Tonies CRef. 33 it "...encompasses the 
keywords that are the heart of all engineering discipline 
definitions: sound engineering principles, economical, 
reliable, and functional (works on real machines)." The 
critical question is whether we can reason by analogy from 
the sound engineering principles of other (non-software) 
engineering disciplines in general to a set (not necessarily 
complete) of sound engineering principles for software engi- 
neering in particular. Another somewhat less critical ques- 
tion is whether principles that at first appear unique to 
software engineering can be effectively applied to other 
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di scipl 1 nes. 



The former question will be of great concern 



throughout the remainder of this thesis, 

C. THE SOFTWARE ENGINEER 

Ule turn now to the problem of defining, or at least 
identifying, the software engineer. In other engineering 
disciplines, we find "engineers’* in many different roles. 
These range from that of a technician with limited formal 
education to that of a researcher with a doctorate degree. 
They also include many managerial functions- There are 
"chief engineers'* who manage the engineering resources of a 
company, "project engineers** who are concerned with only a 
specific project or product line, **design engineers" who 
create and document designs, "production engineers** who de- 
termine how designs are to be implemented (manuf actured ) , 

"quality assurance engineers" who devise and carry out tests 
on subassemblies and the finished product, **mai ntenance 
engineers'* who perform preventive maintenance, repair and 
field alteration or upgrade functions, etc. In short, when 
we use the term '*engineer** with respect to a particular 
product, we are speaking of anyone employed by the manufac- 
turer who is responsible for any of the technical aspects of 
that product or directly manages those who are- Even the 
most cursory survey of the literature will show that all of 
the above functions have already been identified as being 
important to software engineering- 
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SOFTWARE ENGINEERING ENVIRONMENTS 



The problem with which we are -faced can be stated as 
follows: "How can the productivity of competent software 
engineers at all levels be substantially improved?" Since 
competence is assumed, we must look at how these people are 
organized and used, and at the conditions under which they 
are required to work. In other words, we must examine the 
work environment. 

Environment tends to be a rather all-inclusive term. It 
includes such obvious things as lighting, the architecture 
of the building, layout of office spaces, air quality, noise 
level, etc. It also includes the equipment and tools used 
for the production of products or as aids in carrying out 
other necessary functions (specification, design, main- 
tenance, quality assurance, project management, etc.). 
Equipment and tools typically include all of the machinery 
and tools on the production floor, drafting equipment (de- 
sign and design documentation), test equipment and accurate 
measuring devices (quality assurance), and computers. 

In this thesis, we will focus on the equipment and tools 
portion of the total environment. We will define, for 
purposes of this discussion, a software engineering environ- 
ment as the set of automated tools available for carrying 
out the various activities associated with (1) the formula- 
tion and analysis of the target problem, (2) the speci- 
fication, design, development, implementation, quality 
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assurance, maintenance, alteration, and enhancement of the 
software to solve that problem, and (3) the management of 
the personnel and other resources used in all these activi- 
ties. The purpose of this thesis is to present principles 
that should be used to guide the design of such 
environments. 

E. OUTLINE OF THE THESIS 

In the next two chapters we will build the basic 
knowledge base needed in order to pursue a meaningful dis- 
cussion of software engineering environment design. Chapter 
II will provide a brief historical perspective on how our 
present views of computers and software evolved. The objec- 
tive will be to identify as many prejudices and hidden 
assumptions as possible so we may relieve ourselves of their 
burden. The three main areas of discussion will be the 

programming language, operating systems, and hardware devel- 
opments of the past 40 years. 

Chapter III will present and discuss an outline of the 
general engineering methodology which seems to be common to 
all current fields of engineering. The objective here will 
be to provide a generalized model of the activities we call 
"engineering** with a view toward applying this model to 
software engineering in later chapters. 

Chapter IV will be concerned with software engineering 
issues. Given the background material on the general 
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engineering methodology and the historical perspective ot 
the computer industry, we will analyze why "software engi- 
neering" is not yet a mature engineering discipline. We 
will suggest how the maturation process might be accelerated 
through the software engineering environment concept- 

Chapter V will be concerned with some software manage- 
ment issues. Although we will not have time to examine 
these issues very deeply, we will emphasize their importance 
to the overall software engineering process and we will 
point out some types of automated aids which a software 
engineering environment could provide. 

In Chapter VI we will discuss ergonomic issues. That 
is, we will look at the man-machine interface and emphasize 
its importance to the successful use of interactive tools. 
We will also argue that an integrated environment is needed, 
whereas a mere "toolkit" of loosely related automated aids 
is not sufficient. 

Finally, in Chapter VII we will draw some conclusions 
and address some philosophical issues. In addition, the 
principles which will be developed throughout the thesis 
will be gathered together in a compact form and placed in 
the appendix. 
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II. 



HISTORICAL PERSPECTIVE 



A. PROGRAMMING LANGUAGES 

1 - iD^CPductign 

Even though the general history o-f programming lan- 
guage evolution is well known, we will review part of it 
here for the purpose of highlighting certain events and 
concepts that are key to our understanding of the present 
state of affairs regarding software engineering environ- 
ments. We will accomplish this by following a line of de- 
scent that leads more or less directly from the first major 
high-level language, FORTRAN, to one of the most recent - 
Ada. In particular, we will wish to ponder the question of 
which software engineering problems are best addressed by 
programming language design and which are best addressed by 
other means- 

In CRef. 53, MacLennan develops a number of prin- 
ciples which can be applied to the design of programming 
languages. However, these principles are, by and large, 
applicable to most engineering design problems and are not 
specific to language design. For this reason, they are 
listed in Appendix A for ease of reference- In spite of 
their general nature and the fact that he uses some very 
early programming techniques (pseudo-code i nterpr eter s) and 
languages (FORTRAN and Algol) to illustrate them, only one 
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of the principles he cites seems to have been consciously 
followed in those early days. Significantly, it is the 
first one mentioned in CRef. 5D and is quoted below: 

The Auto»ation Principle 

Automate mechanical, tedious, or error-prone activities. 

The key to programmer productivity seemed to lie in 
providing higher levels of abstraction for programming pur- 
poses which could then be reduced to machine level instruc- 
tions by automatic means. Given the lack of previous expe- 
rience and the hardware limitations of the period, the 
higher level languages developed prior to 1970 turned out 
remarkably well. However, there were some unspoken, perhaps 
even unconscious, assumptions about software that became 
increasingly false with the passage of time. These included 
such assumptions as 

Programs apply to specific, well-defined problems. 

Programs are at most a few thousand lines long. 

Programs have a relatively short life expectancy. 

Programs are rarely modified. 

Mhile the incorrectness of some of these became apparent to 
writers of "systems software" <e.g. operating systems and 
compilers) as early as 1960, their i ncorrectness with 
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respect to "applications software" (i.e. programs written by 
users tor their own purposes) was not appreciated until 
much, much later. Because high-level languages were thought 
ot as applying more to applications software than to systems 
software, this lack of foresight was the main contributor to 
the shortcomings of high-level languages and the paucity of 
other software development tools for many years- 

2- fortran 

The first major high-level language was FORTRAN. It 
was developed by John Backus of IBM between 1954 and 1958. 
FORTRAN is an acronym for FORmula TRANslation and this is 
precisely what the language was designed to do. It was 
aimed at the numerical problems of the scientific community. 
It was heavily machine dependent, as the correspondence 
between its control structures and the branching instruc- 
tions of the IBM 709 computer shows. From a linguistic 
point of view, it was '*grown'* more than designed. In fact. 
Backus is quoted in CRef. 5] as saying (in 1978), "As far as 
we were aware, we simply made up the language as we went 
along. We did not regard language design as a difficult 
problem, merely as a simple prelude to the real problem: 
designing a compiler which could produce efficient pro- 
grams. " Although FORTRAN was to come under heavy fire on 
linguistic grounds in later years, it was enormously suc- 
cessful. It proved the viability of high-level languages 
when many doubted their feasibility and it was a huge 
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commercial success. Much o-f its initial machine-dependence 
was removed in later versions and it became available on the 
computers o-f almost every manu-f acturer . 

3. 0l99l 

After FORTRAN proved that programs written in high- 
level languages could be automatically translated to ef- 
ficient and logically equivalent machine language programs, 
a number of computer scientists on both sides of the Atlan- 
tic decided that a new "universal", machine independent 
language suitable for communicating algorithms between hu- 
mans as well as between humans and machines was needed. The 
end result was a language called Algol. The work on Algol 
produced a great many significant advances in programming 
language design, probably more than any other single piece 
of work to date. Nevertheless, its goals were essentially 
the same as those of FORTRAN and it too suffered from the 
tacit assumptions stated above. 

Algol suffered from another problem as well. In 
their enthusiasm for increased expressive power, the design- 
ers of Algol included some very general control structure 
constructors. These made it possible to represent some very 
sophisticated algorithms very compactly, but at the same 
time made those representati ons almost unreadable and in 
some cases misleading to all but the most experienced. 
Despite this generality, Algol remained a relatively compact 
language until its 1968 (Algol-68) incarnation. 
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4. 



PL/I 

Algol wasn't the only language to suffer from the 
drive to generalize. While FORTRAN and Algol were aimed at 
scientific computing, another language named COBOL (COmmon 
Business Oriented Language) was developed. Having never 
jumped on the Algol bandwagon, IBM wanted to develop a 
“universal** language of its own aimed at both the scientific 
and business communities. It therefore began an effort in 
1964 to extend FORTRAN with ideas from COBOL and Algol. It 
soon became evident that instead of an extended FORTRAN, a 
completely new language would result. This language was 
called PL/I (Programming Language One). It was an extremely 
large and complex language, the mastery of which was next to 
impossible. It had so many features which could interact in 
so many different ways that it wasn't even possible for an 
individual programmer to learn only a subset of features for 
his own use while ignoring the remainder. The drive to 
incorporate in one language all the features that any pro- 
grammer could possibly want or use very nearly resulted in a 
language that no programmer could understand. 

5. P§sca^ 

Other significant events in software development 
were taking place. In 1966 Bohm and Jacopini published 
CRef. 63 proving that any flowchart can be converted to one 
containing only certain types of flowchart elements - the 
so-called *'structured programming** forms. The significance 
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o-f this work was that it showed complex and undisciplined 
control structures to be unnecessary. In the years that 
followed, many computer scientists argued that use of com- 
plex control structures was also unwise. A new concern for 
such things as software readability and reliability was 
growing as some of the earlier assumptions about the nature 
of software began to crumble under the weight of experience. 
Unfortunately, those assumptions listed earlier still re- 
mained largely intact as shown by the following excerpt 
taken from Dijkstra's now famous 1968 letter CRef. 73 to the 
editor of the Communications of the ACMZ “My first remark 
is that, although the programmer's activity ends when he has 
constructed a correct program, ...” 

In 1970 the language Pascal was introduced. Its 
control structure constructors were simple and direct imple- 
mentations of those associated with the new concept of 
“structured programming" . Pascal was also a strongly typed 
language and had a block structure similar to that of Algol. 
This new language represented a quantum change in the nature 
of programming languages in its attempt to encourage and/or 
enforce certain programming practices. The emphasis on pro- 
gramming style was consistent with its goal: to be a suit- 
able language for teaching programming. Because of its 
small size, excellent (though certainly not perfect) design, 
rich and efficient set of data structure constructors, and 
its strong typing it has not only met its original goal; it 
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has been success-f ul 1 y extended and used in many "real world" 
applications. Like Algol before it, Pascal has influenced 
the design of almost all later languages, including one of 
the latest - Ada. 

6. Ada 

Finally during the seventies the early assumptions 
about programs having a short life, being rarely modified, 
being relatively small, and being applied to specific, well- 
defined problems were revealed and discarded — violently. 
Everywhere one turned in the computing world, the phrase 
"software crisis" seemed to be emblazoned in neon lights. 
The situation wasn't far short of a general panic. Everyone 
seemed to have an idea of what the "key" problem was and 
thought that solving that one problem would cure most, if 
not all, of the software industry's ills. Of course, for 
each such perceived problem there was at least one proposed 
solution. The only central point of agreement was that 
something had to be done. 

Into these stormy seas was launched the Department 
of Defense project to develop a new standard language to 
meet the needs of software development for "embedded" compu- 
ter applications, i.e. situations where a computer is con- 
tained in and an integral part of a larger system (e.g. 
weapons systems and command, control and communications 
systems). DOD's experience with such software had been an 
expensive one up to this time. A wide variety of languages 
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were employed and some of them were used nowhere else in the 
world. This made software maintenance and the integration 
of subsystems from different vendors extremely difficult. 
The outcome of the work to overcome these and other dif- 
ficulties was the programming language Ada. 

Like PL/I, Ada has drawn on several earlier lan- 
guages and like PL/ I it is a very large and complex lan- 
guage. However, the reasons for its large size and com- 
plexity are quite different from those of PL/I. The two 
main driving forces behind Ada's size are its generalization 
and improvement of Pascal features and its attempt to in- 
corporate a number of software engineeri ng/management func- 
tions. For example, software design reusability is ad- 
dressed by generic packages which contain templates for 
generating Ada code. Like many other languages, Ada sup- 
ports separate compilation of modules but unlike them it 
also provides a considerable amount of error checking across 
modules. It remains to be seen if these and the many other 
features introduced by this new language have been chosen 
and implemented with sufficient care to avoid repeating the 
PL/I experience. 

Another aspect of Ada which is of particular in- 
terest here is the inclusion of an Ada program support 
environment (APSE) in DOD's overall software development 
strategy for embedded systems. The rationale for this is 
described in CRef. 83. Unfortunately, the implementation of 



23 



a standard APSE is still far in the future even though at 
least one Ada compiler has already been implemented and 
certified. Nevertheless, the ongoing DOD effort stands as 
the most comprehensive approach to a software engineering 
environment to date. 

7. Summary 

The first high-level language had only one goal: 
the automatic translation of mathematical notation to effi- 
cient machine language programs. Later, more expressive 
power and generality were incorporated with little thought 
given to the consequences or implications of such a move. 
These traits and the changing nature of the software being 
developed caused many to question the wisdom of large com- 
plex languages. Many programming practices were questioned 
and a number of techniques such as structured programming, 
modular programming, etc. were devised. Out of this work 
came languages that in addition to performing the transla- 
tion function also encouraged these newer techniques. While 
this initially resulted in a smaller, simpler language, the 
latest offering has tried to address so many programming 
issues that its great size and complexity has led many to 
doubt its viability. To quote C. A. R. Hoare CRef. 9D on 
Ada, ”We relive the history of the design of the motor car. 
Gadgets and glitter prevail over fundamental concerns of 
safety and economy. *' 
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B- OPERATING SYSTEMS 



In the very earliest days of electronic computers, those 
who designed and built them also operated and programmed 
them. The early machines were dedicated to single users. 
Before a program could be run, there was a certain amount of 
"setup” work to be done to get the machine ready. It wasn't 
long before the oper ator s/pr ogr ammer s wrote software to 
automate some of the setup activity. This marks the begin- 
nings of what we now call operating systems. 

As long as computers were dedicated to single users, 
operating systems were only used to provide services to the 
human operator. Later, as computers grew into complex com- 
puting systems capable of processing many programs concur- 
rently and utilizing a large number and variety of periph- 
eral devices, software was developed to manage system re- 
sources. The objectives of this management included (1) 
security to control the interaction between applications 
programs and the hardware and to keep applications programs 
from interfering with each other, and (2) maximum throughput 
to ensure that the system's resources were utilized as 
efficiently as possible. 

By this time computers were being widely used commer- 
cially and customers demanded, in addition to an operating 
system to manage hardware resources, that a growing number 
and variety of service or utility programs be supplied as 
well. Vendors supplied file management subsystems, high 
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level language compilers, accounting software for resource 
usage, etc. Since all of these were tightly coupled with 
the "bare** operating system and were supplied along with it 
in one package, the entire package came to be called **the 
operating system-" As the hardware continued to grow in 
capability while decreasing in cost, interactive use re- 
placed the previous batch mode of operation. This led to 
even more demands on the operating system and its associated 
utilities. Interactive communi cati ons with large numbers of 
terminals, on-line utilities for file creation and manipula- 
tion, and text editors were but a few of the many additional 
demands placed on "operating systems.** 

What all this means is that, in effect, software devel- 
opers have come to view the operating system as the **soft- 
ware engineering environment." Unf ortunatel y, so many de- 
mands are placed on an operating system that its developers 
can give only limited attention to software engineering 
utilities. So far, these are usually limited to assemblers, 
compilers, subroutine libraries, a limited object code 
librarian facility, linkers, loaders, general purpose text 
editors and file manipulation utilities, assembly level 
debuggers, and, with luck, source level debuggers that are 
consistent with the compilers. As we will see in Chapter 
IV, these tools address only a small fraction of the funda- 
mental needs of a "software engineering environment.*' 
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c. 



HARDWARE 



We will not recount the history of computer hardware 
here since it is so well documented elsewhere. However, it 
is important to examine the changing nature of human-machine 
interaction that has resulted from hardware advances. 

We have already noted how the difficulty of machine 
language programming led to the invention of high-level 
languages and how the desire to automate operator functions 
led to the development of operating systems. Another impor- 
tant character i sti c of the earlier computers was that they 
operated almost exclusively in batch mode. Programs were 
recorded on punched cards and submitted in their entirety 
for translation to machine code. Programs were altered by 
removing, replacing and moving punched cards within the 
"source deck." Since nothing could be done to automate this 
manual process, software programming aids were necessarily 
limited to the features of the programming language itself, 
the diagnostic abilities of the compiler, and the diagnostic 
abilities of the operating system (register status reports 
on program abortion, "core dumps", etc). 

When the hardware became capable and cheap enough to 
support interactive users and vast amounts of online stor- 
age, the possibilities for new applications, including soft- 
ware engineering environments, exploded. Furthermore, the 
continued decrease in computing costs means the possibili- 
ties are continuing to expand at a dizzying pace. We can 
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now put the computing power, speed and data storage capa- 
bility o*f what was a multimillion dollar mainframe computer 
a few years ago on the desk of every individual in an or- 
ganization, if we so desire. Likewise, the cost of graphics 
display devices have fallen into the realm of af f ordabi 1 i ty . 
If one picture really is worth a thousand words, there are 
few places where pictorial representat i ons would be more 
welcome than in software development. Whether we can effec- 
tively apply such vast amounts of computing power to appli- 
cations in general will depend in large part on how much of 
that power we can apply to software engineering environments 
in particular. 

Another hardware topic currently under vigorous debate 
involves instruction sets. We have seen how hardware avail- 
ability influenced the growth and nature of high-level pro- 
gramming languages. This was not a one-way street, however. 
After a time, hardware designers began to consider how high- 
level languages would be implemented on the hardware they 
were designing. Soon they began to include instructions 
specifically for certain high-level constucts. For example, 
special index registers and instructions were included for 
iterative loops and array indexing. The hardware stack, 
immensely useful for languages that permitted recursion, was 
another feature frequently added (see p. 39 of CRef. 103). 
Even more elaborate and "high-level" instructions have been 
included on some machines. 
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This trend has been called into question by supporters 
of a concept popularly called "RISC** - Reduced Instruction 
Set Computers CRet. 111. RISC adherents claim that a small 
instruction set made up of very simple and very fast opera- 
tions is better than a very large one more (apparently) 
attuned to high-level languages. They claim increased ef- 
ficiency based on research which indicates that a reasonably 
"intelligent" compiler could do more optimization and there- 
fore generate more efficient object code than it could if 
forced to use the **hi gher-1 evel " and more complex instruc- 
tions. They also claim more reliability based on the old 
notion that simple machines are inherently more reliable 
than complex ones. There may be a lesson here for designers 
of software engineering environments. Which is better, a 
simple language supported extensively by the environment or 
a large, complex language that presumably requires less 
support? 

D. CONCLUSIONS 

The vast majority of research and development effort ex- 
pended in the computer field since its beginnings in the 
1940s has been directed toward three major areas: program- 
ming languages, operating systems, and hardware. The criti- 
cal importance of software was recognized in the early 
seventies along with a rather long list of problems encoun- 
tered in the design, development, and maintenance of 
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reliable, effective software. The primary vehicle for ad- 
dressing these problems was language design. Pascal and Ada 
are two related examples of languages designed during this 
period. However, the persistence of the "software crisis" 
indicates that language design alone, while important, will 
not solve the pressing problems of the software industry. 
Advances in hardware and operating systems have made a great 
deal of computing power available to software developers but 
they have not yet harnessed more than a tiny fraction for 
their own purposes. 
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III. ENGINEERING METHODOLOGY 



A. INTRODUCTION 

The “engineering" o-f a product can be thought of as four 
basic types of activity. These are design, implementation, 
maintenance/evolution and the management of all these activ- 
ities. We will discuss each of these briefly in the 
sections that follow. 

Before we begin to look at the general nature of en- 
gineering as a human activity, we should dispense with one 
particular misconception that seems to haunt the software 
industry. In CRef. 121, Peters notes that, "Many software 
developers who .lack an engineering background think of en- 
gineering as an; exact discipline that produces formulated, 
precise, closed— form solutions to problems. The inexacti- 
tude associated with software design seems intolerable to 
many designers, who feel that if there were a true engineer- 
ing discipline for software, all estimating and scheduling 
problems would go away." He continues, "Actually, nothing 
could be further from the truth: Engineering depends as 
much on common practice and empirical knowledge as it does 
on scientific fact." Certainly this observation is borne 
out by the number ot times "rules of thumb," "safety fac- 
tors," and the like are used in all engineering disciplines. 
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As we look at the general engineering method for clues 
regarding the way we should conduct software engineering 
endeavors, we must not lose sight of our objective. We 'wish 
to improve the ability of software engineers to produce h.igh 
quality software efficiently. Any such improvement that 
promises significantly more in benefits than it consumes in 
resources is worth exploring. 



B. DESIGN 

kz. 10 tC 9 duct i_gn 

According to Jensen and Tonies CRef. 3], the engi- 
neering design process can be broken into six phases. These 
are illustrated in Figure 1. Note its neat, straight line 
structure. While it provides a good way organize the dis- 
cussion which follows, it is not very r epr esentat i ve of the 
way an engineering project actually proceeds. Recognizing 
this, Jensen and Tonies provide a second diagram in HRef. 33 
which is reproduced here as Figure 2. With its numerous 
feedback loops, it is a much more accurate rendition of 
actual engineering processes. 

One other feature of these diagrams requires com- 
ment. The “Implementation** phase is included because of the 
importance of its feedback to all the other phases. In the 
discussion which follows, implementation will not be con- 
sidered part of the design process but, 
will become clear, as a separate entity. 



for reasons which 



recognition of problem 
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Engineering Design Process 




Fig. 2 Realistic Engineering Design Process 
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Probl em Formul at i on 



According to CRef. 31, the inputs to the problem 
formulation process are the recognition of the problem to be 
solved, solutions to similar problems, and a fair amount of 
irrelevant and misleading information. The output is a 
general , but accurate, statement of the problem to be 
solved. The primary goal of the engineer in this phase is 
to gain a broad perspective on the problem and to remove 
prejudices caused by "misleading opinions, current solu~ 
tions, and standard ways of viewing the problem." CRef. 31 
This usually involves a great deal of human-to-human com- 
munication as all parties try to bridge what Milliam James 
character i zed as, "The most immutable barrier in nature...", 
the one, "... between one man's thoughts and another's." 

Another objective of the engineer at this time is to 
avoid thinking of possible solutions. A method frequently 
used is the so-called "black box" technique. Here, the 
problem is viewed as that of finding a process to transform 
inputs to outputs (e.g. steel into car bodies). In this 
phase, the objective is to identify the inputs and outputs 
but to keep the details of the transf ormation process hidden 
in the "black box" that forms the bridge between them. 

PC9bl.em Anal^ys^s 

In this phase, the engineer sets out to sharpen his 
understanding of the problem and to formulate a list of the 
constraints and requirements that will be placed upon any 



solution. These constraints and requirements may be imposed 
by management (e-g- company standards) , the customer (e.g. 
price and delivery date), or nature itself (e.g. strengths 
of materials). Another objective is to develop criteria for 
selecting the best of several possible solutions later in 
the project. Engineers, being pragmatists, normally will 
see several ways of solving any problem and so there must be 
some criteria for choosing among them. 

One of the most useful ways of sharpening one's 
understanding of a large and complex problem is to decompose 
it into successively simpler problems. This technique is 
known as stepp^ise or saccessiue ref inement. Although there 
is no fixed algorithm for this process, engineers usually 
try to do functional decomposition. That is, they try break 
the overal 1 function a device must perform into a set of 
smaller and simpler functions which have a composition 
equivalent to the original total function. Since more than 
one decomposition is possible, there may be several attrac- 
ti ve al ternat i ves. 

During problem analysis it all but impossible to 
keep from thinking of potential solutions. It is natural 
for solutions or partial solutions to suggest themselves 
during the analysis. The disciplined engineer will note 
these and lay them aside for consideration during the search 
and decision phases. The undisciplined engineer may well 
allow his analysis to become biased by a potential solution. 
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4. 



Sear ch 



In this phase the objective is to locate and de- 
scribe as many potential solutions as time and other re- 
sources permit. The broader the field of selection the more 
ideas the engineer will have to draw upon in selecting the 
approach he will finally use. It is important at this point 
that no attempt be made to eliminate potential solutions or 
partial solutions no matter how awkward they might seem on 
the surface. Selection is the objective of the next phase 
while collection is the objective of this phase. 

Up to this point we have been using the term "solu- 
tion" without having defined it in any special way. While a 
special definition is probably not necessary, it is impor- 
tant to realize its use in the current context implies an 
approach or route to be followed in obtaining a complete and 
detailed solution and not the complete solution itself. 

5. Deci^s^on 

This phase is where the various proposals are objec- 
tively compared to find a "best" approach to use for com- 
pleting the solution design in sufficient detail to enable 
implementation. In order to carry out such an objective 
comparison, CRef. 3U proposes the following four steps: 

1. The selection criteria must be defined, and the 
relative weight of the individual elements of the 
cr i ter i a assi gned ; 
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The performance of the alternate solutions with 
respect to these criteria must be predicted as 
accurately as possible; 

3- The performance of the alternate solutions must be 
compared on the basis of their predicted 
perf or mance; 

4. The selection of the preferred solution must be 
made. 

The selection criteria may be based on a number 
diverse aspects of problem solution such as deadlines for 
product delivery, availability of the technology required to 
implement the solution, manuf actur i ng costs, product per- 
formance, reliability, maintainability and ease of use, etc - 
The assignment of weights is necessarily a difficult and 
subjective task but the most difficult part of this process 
is the performance prediction of step two. Such predictions 
can only be based on rough estimates and the judgement of 
the engineer since the solutions themselves are still rather 
vague and ill-defined. Furthermore, it is almost certain 
that none of the proposed approaches will provide the "opti- 
mal** solution <even if one could be recognized as such) 
because the search phase did not exhaust the solution space 
but merely sampled from it. For this reason, it is a very 
poor engineer who can study the design of a very good engi- 
neer without finding some way to improve upon it. 

6. Specif icatign 

This is the phase we most often associate with 
engineering design. It is here that the rough solution is 
refined and developed in considerable detail, and the bulk 
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of the design docunientat i on produced. The design documenta- 
tion is an absolutely necessary and integral part of any 
engineering methodology. Its most obvious purpose is to act 
as the output of the design process and provide all the 
information necessary for actual implementation of the de- 
sign. However, design documentation sees considerable ser — 
vice prior to completion of the design process. It is used 
for design reviews which ensure the continued feasibility of 
the solution and provide others involved in the project an 
opportunity to suggest improvements while also keeping them 
up to date on project progress. Design documentation also 
provides an opportunity for error detection. Drawing check- 
ers can detect and report such things as internal dimen- 
sional inconsistencies, incomplete bills of materials, etc. 
They can also check to make sure that mating parts, if 
within the specified tolerances, will in fact mate in all 
cases. Although this is a tedious, mundane task, it is very 
important to detect and correct such errors before the 
implementation phase begins. Correction of even minor de- 
sign errors during implementation can be extremely expensive 
whereas their detection and correction prior to that time is 
rel ati vel y i nexpensi ve. 

□nee the design has been specified, documented, and 
verified a very important event occurs. Up to now only the 
design staff under the supervision of the project engineer 
has been directly involved. Upon completion, the design is 
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"released** for implementation (production). All of the 
design documentation is then passed from the "engineering** 
(design) staff to the "production** staff. Although this 
does not end the design engineer's involvement in the pro- 
ject, it does reduce it rather sharply. With respect to 
this project, he becomes a consultant to the ''production** 
department- He clarifies the design documentation if 
needed, makes design changes to accomodate unforseen manu- 
facturing difficulties, etc., but is otherwise uninvolved 
with the actual implementation of his design. 

This separation of design activities from implemen- 
tation activities is one of the most important principles of 
modern engineering. In the ''functional decomposition" of 
the engineering process that has occurred naturally over the 
years, design and implementation have become separate 
modules- The interface between them is the design documen- 
tation, which is made up largely of drawings - the well- 
known engineering blueprints- 

C. IMPLEMENTATION 

The last of the phases in the Jensen and Tonies CRef. 31 
description of the engineering design process is that of 
implementation. It should be clear from the preceeding 
discussion why it is considered as a separate entity from 
design in this thesis. It is in this phase that an actual 
artifact is produced according to the specifications of the 
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designer. For purposes oi this discussion, we will postu- 
late a "production sta-f-f" whose responsibility is to develop 
manufacturing and quality assurance methods, and to carry 
them out to produce and assemble parts into a complete 
working product. Often this staff is broken into three 
"departments" - methods, production, and quality assurance. 

When a design is released for production, someone must 
decide how to manufacture and assemble the component parts 
in order to arrive at a finished product. Normally, the 
manufacture of a part requires many operations (e.g. machin- 
ing operations) to be performed in a specific sequence on a 
piece of raw material before completion. This task is often 
given to a "methods department" which must develop these 
sequences of operations along with intermediate and final 
inspections for quality assurance. Once these have been 
specified, they are sent to the production and quality 
assurance departments along with a work request specifying 
how many parts of each type are to be made and blueprints of 
the design engineer’s original drawings. In this way, the 
methods department quite literally "programs" the production 
floor (e.g. machinists and inspectors) with respect to the 
manufacture and inspection of each part. (Keeping the total 
production floor operating efficiently for maximum through- 
put (productivity) and minimum idle time is the job of the 
production department.) This "programmi ng " function becomes 
even more obvious when numerically controlled (NO machines 
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are used. Methods departments also "program" the assembly 
floor in a similar fashion by providing instructions for 
assembling the parts and testing the assemblies to ensure 
they work properly. They may also be charged with develop- 
ing procedures for implementing field modifications to be 
carried out by the maintenance department. 

□nee the manuf actur ing and inspection procedures have 
been determined, production proceeds. We will not attempt 
to analyze this part of the process since it varies consid- 
erably depending on what type of product is being produced. 
For this discussion it is sufficient to assume simply that 
as components are produced they are inspected for "correct- 
ness" at several levels (e.g. parts, subassemblies, complete 
machine) using the inspection criteria contained in the 
design documentation. Rejected components are either dis- 
carded or reworked until they can pass inspection. 

D . MAI NTENANCE/EVQLUT I ON 

All man— made devices require some sort of maintenance. 
Routine maintenance activities (e.g. periodic lubrication, 
preventive maintenance) are specified in the design documen- 
tation. Such things as "wear tolerances" are also specified 
so maintenance personnel can detect when parts need replac- 
ing. When a device begins to malfunction, repairs must be 
made. In such cases the maintenance person must do some 
"trouble-shooting" to locate the cause of the malfunction. 
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His primary aids in this endeavor are past experience and 
the original design documentation. 

In addition to making repairs and performing preventive 
maintenance, maintenance personnel typically must report 
the results of their activities. Reviews of maintenance 
reports and customer complaints and comments often reveal 
design deficiencies or identify needed enhancements. Once 
identified, management must decide whether to pursue them. 
If changes are to be made, the design process described 
above is initiated and the engineering process continues 
from that point with one additional input - the original 
design documentation. That is, the design engineers go 
•*back to the drawing board" with copies of the current 
design and make the necessary changes via the full design 
process from problem formulation to the release of the 
modified design for production. 

E. MANAGEMENT 

If left to his own devices, a good design engineer might 
never complete a design. This is because engineers are 
rarely satisfied with their own designs and can always see 
some way to make them better. However, economic realities 
restrict time and other resources to finite levels. Manage- 
ment must determine these levels and then husband the 
available resources to produce a profitable outcome. 
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CRe-f. 13], 


management has "five 


(1) 


PI anni ng 


(2) 


Control ling 


(3) 


Staf f i ng 


(4) 


Organi z i ng 


(5) 


Directing 


He goes 


on to stat( 


management" which 


mention 


a few of th< 



will consider only the five management functions stated 
above. 

According to CRef. 13D, "Planning is the primary 
function of management and 



Plans are either strategic or tactical. Strategic 
plans identify major organizational objectives and govern 
the acquisition, use, and disposition of resources to 
achieve those objectives. Tactical plans deploy resources 
to achieve strategic objectives. Plans help managers 
decide in advance what will be done, how it will be done, 
and who will do it. 



Plans provide a standard against which progress can be 
measured and communicate management's goals and e:i pectat i ons 
to the organization. 

Organizational structures are created by managers so 
that people can work together effectively and efficiently to 
achieve the desired goal. Once created, the organizational 
structure must be staffed with personnel having the requi- 
site skills and attitudes. When the staffing is completed. 
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the manager must direct and lead the stat-f to the desired 
goal . 

Finally, there is the matter o-f control. No manager can 

be effective if he cannot control his project- Maintaining 

adequate control is just as essential as good planning. As 

% 

CRef- IZl puts it. 



Planning and control are inseparable activities. Un- 
planned actions cannot be controlled because control in- 
volves keeping events on course by correcting deviations 
to plans. Plans furnish the standards for control . Con- 
trols should be diagnostic, therapeutic, accurate, timely, 
understandable, and economical. They should call atten- 
tion to significant deviations and should suggest alterna- 
tive means of correcting the difficulty. 

One of the traditional ways to exercise control in 
engineering is to require management approvals at several 
points in the product's life cycle. During the design 
process, design documents are carefully reviewed, the costs 
and benefits of various design alternatives are carefully 
estimated and compared, compromises are made and finally a 
course of action is approved. This happens many times and 
at many levels before the final design is released. Some 
decision are ’’internal** to the company while others require 
significant customer involvement. Similar things happen 
during the implementation and maintenance/evolution phases. 
The importance of the control function cannot be over- 
emphasized. 
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F. DESIGN DOCUMENTATION 

1 • lO^Coduct^gn 

We have seen that design documentation is used in 
all aspects o-f engineering. Because o^f its crucial impor- 
tance to engineering methodologies, it deserves closer exam- 
ination. We will now try to determine those -features which 
contribute to its central role in the engineering process. 

2. 9f 

Engineering design documentat i on provides descrip- 
tions o-f the product at many levels o-f abstraction. There 
is a hierarchy o-f descriptions that vary in detail -from the 
general outline oT the finished product down to the most 
intimate details o-f the smallest component part. In mechan- 
ical engineering, -for example, there are "detail drawings" 
o-f each unique part and various levels o-f "assembly draw- 
ings" for the assemblies and subassemblies that make up the 
final machine. As the assemblies become larger, their rep- 
resentations must necessarily show only major features while 
suppressing many details. However, sometimes a particular 
feature is shown in great detail by superimposing a "magni- 
fied view" on an otherwise high-level representat i on . This 

demonstrates the property of "fine granularity" present in 
engineering design documentation. Fine granularity may be 
defined as the ability to simultaneously display different 
levels of abstraction so that both the details of a feature 
and the context in which that feature occurs may be shown- 
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This ability to represent a complex device at vari- 
ous levels o-f abstraction is the key to engineer's ability 
to design complex devices that actually work. If the engi- 
neer could not decompose a complex design problem into a set 
of smaller and simpler design problems with correspond! ng 
smaller and simpler implementations, modern technology sim- 
ply would not be possible. 

There is often more than one conceptual view of a 
product and its components. In electronics engineering, a 
logic circuit can be viewed as a set of connected transis- 
tors, capacitors, resistors, etc. It can also be viewed in 
terms of logic gates (AND, OR, NANO, XOR, etc.) which are 
represented by entirely different symbols from those used to 
depict the electrical components. Even in mechanical engi- 
neering we have "exploded views" of assemblies to illustrate 
how the assembled parts relate to one another even though 
the parts will never actually appear in the "exploded" 
conf i gurat i on . 

4. Completeness 

Taken as a whole, the design documentation provides 
a complete specification from which the artifact may be 
implemented. It specifies both the "perfect" artifact and 
the types and degrees of imperfections that can be toler — 
ated. Design documentation does not, however, specify how 
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the implementation is to be accomp 1 i shed - Different imple- 
mentors are free to employ different methods to accomplish 
the same end- 
s' 

Design documents tend to be universally understood 
by engineers in the same field (mechanical, electrical, 
etc.) regardless of any differences among them including 
national origin. That is, a mechanical engineer in the 
United States can largely understand the design documen- 
tation generated by a mechanical engineer in Japan even 
though neither engineer has met the other or even under- 
stands the other's native tongue. This is because engineer- 
ing design documentation depends heavily on graphical repre- 
sentations and the use of standard symbols and formats 
accepted worldwide, which together form a more-or-less **uni- 
versal design language". 

6- Hi^gh Cost 

The generation of design documentation is an ex- 
tremely expensive process. Often years of design effort are 
expended before the first component of the end product is 
produced. The necessity of this large "design overhead" has 
long been recognized and accepted by the engineering profes- 
sion. This is because the investment is repaid many times 
over in reduced communi cat i ons costs throughout the pro- 
duct's life. Without design documentation, the designer 
would have to either perform all the engineering functions 
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(design, implementation, maintenance, etc.) himself or 
personally educate all those responsible for non-design 
activities. 

The three immediately preceeding character i st i cs 
make the design documentation of its products one of the 
most valuable and closely guarded assets of a company. 
Because of their completeness and universality, design docu- 
ments could be used by competitors to produce the same or 
similar products. The expense of their development makes 
them attractive targets of industrial espionage since even 
their reproduction from an actual artifact is an extremely 
expensive proposition. 

G. CONCLUSION 

We have looked at the general engineering methodology 
used to design, implement, maintain and improve a product. 
In so doing, we found that a central and crucial role is 
played by the design documentation produced by the design 
engineers. In fact, the design documentation is essential 
to all ** engineering” aspects of the product life cycle 
including the design process itself, the production of the 
product, the maintenance of the product, the enhancement or 
evolution of the product over time and the management of all 
these activities. 
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IV. SOFTWARE ENGINEERING ISSUES 



A. INTRODUCTION 

Before we can call ourselves "software engineers" we 
must subscribe to some software engineering methodology. We 
have already described the general engineering methodology 
in use today. However, this description lacks the detail 
necessary for actual practice. 

In the last fifteen years, a number of software develop- 
ment techniques have come into being but a complete engi- 
neering methodology does not yet seem to exist. There are a 
number of companies whose sole business is software genera- 
tion for various customers and many others which develop 
significant amounts of software "in-house" for their own 
purposes. We could analyze the sof tware-rel ated activities 
of these companies to determine their "software engineering 
methodologies." In so doing, we would probably find that 
most really have no well defined methodology. In other 
words, if we were tasked with developing a software engi- 
neering environment for any of these firms, we would face 
all the same problems and difficulties we face when design- 
ing software systems for other "unsophisticated" users. We 
would have to listen to the customer’s stated needs and 
desires and then figure out how he really operates and what 
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he really needs and wants. We might even have to change his 
way o-f doing business to enable him to meet his goals. In 
short, we must know what we are trying to support before we 
can support it. This leads to the following principle: 

Methodology Support Principle 

A software engineering environment should be designed to 
support a specific engineering methodology. 

The central position of the engineering methodology in 
the “ecology of software development environments** and its 
eight essential character i sti cs are given in CRef. 143. 
These eight character i st i cs basically include features 
already identified here (in rough form at least) but they 
are included as Appendix C for easy reference. 

An interactive software engineering environment must 
address three basic classes of issues - (1) technical, (2) 
managerial and (3) ergonomic. These are not strictly or — 
thogonal because real environments have two fundamental 
properties. First, **Everything is connected to everything 
else** and, second, **There is no such thing as a free 
lunch.** Taken together, these character i st i cs imply that 
altering one feature of an environment will have some effect 
on the remainder of the environment. However, for discus- 
sion purposes, we will treat technical, managerial and ergo- 
nomic issues separately although we will see a good deal of 
overlapping among them. 
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B. TECHNICAL ISSUES 



^ • §9f Sugegr t 

When the word "engineering" is mentioned two things 
immediately come to mind - technology and blueprints. Engi- 
neers are people who design devices and structures which can 
be implemented using current or -forseeable technology, and 
who document these designs with engineering drawings (blue- 
prints) and related materials. The importance of design 
documentation to the engineering process and the essential 
properties of this documentation were described in the pre- 
vious chapter. 

Let us now consider the term "software engineering". 
Certainly we should associate "software engineering" with 
"technology" since it is part of the computer industry which 
is one of the most technologically advanced and rapidly 
evolving industries on the planet. But where are the blue- 
prints? What does a "software blueprint" look like? Just 
how does one "design" a software system or even a part of 
one? Given a "design", how can it be communicated to an 
implementor? If there is a "key" to the software crisis, it 
most likely will be found in the answers to these questions. 

While there is no software design documentation 
system that enjoys all the advantages possessed by those of 
the other^ more mature, engineering disciplines, there are a 
a number of documentation techniques that have been pro- 
posed. One of the oldest of these is flowcharting, which 
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can be traced back to pre-FORTRAN days according to CRef- 
153. Although it was widely used -for a time, -flowcharting 
fell into dis-favor -for a number o-f reasons. It was regarded 
as cumbersome because the time and e-f-fort required to con- 
struct -flowcharts was significant. Brooks CRef- 161 charac- 
terized flowcharting as a, - space— hoggi ng exercise in 
drafting." Furthermore, since the software implementations 
of the designs represented by flowcharts were more easily 
altered than the flowcharts themselves, programmers tended 
to modify the software without making correspondi ng changes 
in the flowcharts. As Yourdon CRef. 171 observed, "... 
flowcharts are rarely maintained with any enthusiasm after 
the program has been finished." Hence, the implementation 
soon deviated from the design and so the design documents 
were discarded. (Yes, this is engineering heresy!) 

There were other problems as well. Flowcharts rep- 
resent only the flow of control through a program. This is 
like having blueprints with only one view. Ledgard and 
Chmura CRef. 181 argue, "... program flowcharts can easily 
suppress much useful information in favor of highlighting 
sequential control flow." Hence, many important features 
cannot be seen clearly and some cannot be seen at all. 

Another problem lay in the designs themselves. Be- 
fore the advent of "structured programmi ng " , the control 
structures in most programs could only be described as 
"helter — skelter" - that is, no particular structure at all. 
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Con-fused 



"designs" resulted in equally con-fused -flowcharts 



and program code. 

Perhaps the greatest problem was one which remains 
to this day. There is no more signi-ficant indication o-f 
so-ftware engineering’s immaturity than the lack o-f separa- 
tion between design and implementation activities. In the 
pre-face to CRe-f. 191, Chu states, "The application o-f engi- 
neering methods and practices to so-ftware development im- 
plies (1) the separation o-f so-ftware design -from so-ftware 
implementation and (2) a so-f tware-bluepr int interface be- 
tween software design and software implementation." As long 
as design and implementation remain inseparable, engineer- 
ing in the modern sense cannot take place. This was the 
most important reason flowcharts were largely abandoned. 
Because the designer was also the implementor (programmer in 
both cases), the making of flowcharts or other design docu- 
mentation served no useful purpose in his view. As Yourdon 
CRef. 171 also observed, "Indeed, most programmers will 
admit that they rarely bother writing the flowchart until 
the program has been finished (and then only because the 
manager insisted on it)..." In other words, software is 
often developed k^ithoat any design documentation at all. 

Other design documentation aids have been proposed 
in the years since flowcharting was introduced. These in- 
clude Nassi -Shnei derman Charts CRef. 201, HIPQ (Hierarchy 
plus Input-Process-Output) CRef. 211, PDL (Program Design 
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Language) CRef. 22D, 



Structure Charts CRef. 



9 



and the 
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"software blueprints" of CRef. 193 as well as some others. 
This last technique at least strives toward providing all 
the essential char acter i st i cs of engineering design documen- 
tation although it still lacks the richness and variety of 
the more mature documentation systems- Chu's "software 
blueprint" provides three levels of abstraction, four 
processing data (as distinguished from control data) types, 
seven processing data structures, two control data types, 
two control data structures, a large number of high-level 
data operators, seven reference structures (e.g. procedure 
reference structure, data ref erence structure) , and some 
other constructs (e.g- defined data types) as well. This 
technique does not make extensive use of graphical 
representati ons, although Chu allows that such representa- 
tions could be usefully employed in conjunction with the 
"software blueprint- " 

All of the above aids seem to have been used with at 
least some success. Unf ortunatel y , we do not have space 
here to explore them in detail- For our present discussion, 
the details are not that important. The important thing for 
designers of software engineering environments to realize is 
that some reasonably complete design documentation system 
must be chosen before a software engineering environment 
that supports software design may be developed- We state 
the following principle: 
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Design Documentation Principle 
A software engineering environment should support a design 
documentation system that is (1) complete, (2) capable of 
representing appropriate levels and types of abstractions 
with fine granularity, (3) universal, and (4) economical. 

Completeness and universality serve the same func- 
tion in software engineering as in other engineering disci- 
plines. They allow design to be largely divorced from other 
engineering activities while reducing the total communica- 
tions burden over the product’s life. Although universality 
may seem an impossible goal at this early stage of software 
engineering’s development, we can begin by following the 
example set by the other engineering disciplines. That is, 
we need to develop graphical symbols and standard formats 
for representing the various important features of a soft- 
ware design. Flowcharts and hierarchy charts already can be 
considered universal and adaptations to increase their util- 
ity would be very valuable for this reason. Easily under- 
stood graphical repr esentat i ons of certain common data 
structures such as stacks, queues, and linked lists could be 
developed without much difficulty. In short, the key to 
universality lies in the consistent use of graphical repre- 
sentations, formats (both graphical and textual), and sym- 
bols that are easily recognized even though only limited 
standards for these currently exist. 
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Abstractions also serve the same function as in 



other disciplines but we will list a few examples here to 
show how they apply to software engineering. Programs can 
be viewed in many ways and so several types of abstraction 
are useful. The most obvious and familiar view is the 
textual (program listing) one which is often "pretty print- 
ed" to emphasize certain structures. (As design documents, 
listings can at best be regarded as analogous to the "de- 
tail" drawings of the mechanical engineer. It is probably 
best think of listings as representing an implementation 
rather than a design.) Flowcharts depict control flow, 
hierarchy charts show the procedure reference structure, 
data flow diagrams illustrate how and when data items are 
modified, etc. The reader can no doubt think of several 
other types of useful abstractions. 

By having a design documentation system for represent- 
ing the various aspects of a software design, we can analyze 
the design to see if it satisfies various design criteria. 
For example, if we can display all of the connections be- 
tween modules, we can estimate levels of coupling. We can, 
like the drawing checkers mentioned in the previous chapter, 
inspect the design for technical flaws, inconsistencies, and 
adherence to design and documentation standards mandated by 
management. This suggests the following principle: 
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En f ortzement/ Pizd Princi pie 

A software engineering environment should enforce tech- 
nical correctness and conformance with management policies 
while aiding the user in maintaining these standards. 

It should be made clear that "technical correctness" 
in this context does not necessarily mean "proof of correct- 
ness" in the formal sense. Although engineers of all disci- 
plines use mathematical calculations in creating and check- 
ing their designs, rarely if ever is the "correctness" of a 
design confirmed by a formal mathematical proof. We are 
more concerned here with such mundane things as ensuring 
that the interface specifications between modules are con- 
sistent or that the design does not call for the use of side 
effects. Of course, where proofs of correctness can be 
accomplished economically, they should be done. 

There is an important corollary to the Enforcement/ 
Aid Principle. Designs change frequently while they are 
being developed as well as less frequently after release. 
Steps must be taken to ensure that changes to one part of a 
design are accompanied by appropriate changes to the remain- 
der of the design in order to maintain consistency. It is 
altogether too easy to make a seemingly innocuous design 
change that actually proves to have widespread ramifica- 
tions. This leads to the 
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Cons i stenc y Princi pi e 



"Permanent** alteration ot one view of a design should not 
be "accepted** by the environment until all related views 
are made to be consistent with the Change- 

Related views include all levels and types of abstraction 
that show either the altered module or modules that inter- 
face with it- **Permanent ** and ** accepted** are quoted to call 
attention to the need for allowing temporary inconsistencies 
so local evaluation of alternative design changes and envi- 
ronmental transition states may be accomodated- 

It is difficult to say where design ends and imple- 
mentation begins in software development. Here, we will 
define implementation as that activity which transforms a 
software design into an executable program or system of 
programs. We will take executable to mean either directly 
executable on the target hardware (machine code) or trans- 
latable by automatic means to a form that is directly exe- 
cutable. Thus, programming languages are considered dis- 
tinct from design languages. This distinction is far from 
being absolute, however. For example, Pascal could be used 
as part of a design language system for specifying assembly 
language programs to be created by hand if a compiler for 
the target machine either did not exist or generated intol- 
erably inefficient machine code. Another thing making the 
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design/implementation boundary -fuzzy is that no matter how 
complete the design, programmers are always allowed some 
leeway and so per-form some detailed design -functions. 
There-fore, placement o-f the desi gn/ i mp 1 emen tat i on boundary 
will be a di-fticult chore -for the developers of software 
engineering methodologies for the forseeable future, 
a. Enf orcement /Ai d and Consistency 

Implementors face many of the same sorts of 
problems as designers but in a different context. For 

example, the Enf orcement /Ai d and Consistency principles can 
be applied to such things as ensuring consistency between 
the implementation and the design, enforcing various pro- 
gramming standards and policies, enforcing syntactic and 
semantic rules of the programming language being used for 
the implementation while aiding the programmer in conforming 
to those rules, etc. 

When applied to programming itself, the Enforce- 
ment/Aid principle can be extremely powerful. It is, in 
fact, the driving principle behind most modern interactive 
'*pr ogr ammi ng environments'* including the Cornell Program 
Synthesizer CRef. 241, the DWIli (Do What I Mean) feature of 
Interlisp CRef. 251, and any syntax -di rected editor. These 
tools show that there is nothing sacred about having the 
compiler perform enforcement functions. In fact, given 
today's computing power and the prevalence of interactive 
use, one could effectively argue that compilers should not 
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be in the enforcement business at all but should handle only 
the translation function from a form that can be made human- 
readable to a form suitable for machine execution. Note the 
possibility here of storing a program in an intermediate 
**bi di recti onal ** form that could be "unparsed** into a textual 
or other understandable form (one direction), or directly 
translated into executable machine code (other direction) by 
either an interpreter or a compiler. 

The Enf orcement/Aid principle can be used to de- 
fine a completely new programming language or effectively 
alter an existing one. For example, in CRef. 263, Kernighan 
and PI auger describe RATFOR, a preprocessor for FORTRAN that 
adds Pascal-like control structure constructors and charac- 
ter manipulation to FORTRAN by translating these constructs 
from RATFOR to FORTRAN which can then be translated into 
machine code by the FORTRAN compiler. A syntax -di rected 
editor for RATFOR that restricted the use of the GO TO 
statement (which RATFOR does not) could aid in the en- 
forcement of structured programming techniques on FORTRAN 
programmers, particularly if it was interactive (which 
RATFOR is not) and provided templates (like the Cornell 
Program Synthesizer) and other aids for program construc- 
tion. It is easy to see how strong typing could, in es- 
sence, be added to FORTRAN as well. 

The Enf orcement/Aid principle can also be used 
to effectively create a subset of a language. In fact, the 
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Cornell Program Synthesizer does precisely this for PL/I. 
□f particular interest in this regard will be the relation- 
ship between Ada and various implementations of the APSE. 
While DOD has decreed that it will allow no subsets of Ada, 
it is difficult to see how this can be effectively pre- 
vented. Ada’s large size and complexity practically beg for 
some sort of subsetting- As Hoare observes in CRef. 9], 



It is not too late! I believe that by careful pruning 
of the ADA language, it is still possible to select a very 
powerful subset that would be reliable and efficient in 
implementation and safe and economic in use. The sponsors 
of the language have declared unequi vocal 1 y , however, that 
there shall be no subsets. This is the strangest paradox 
of the whole strange project. If you want a language with 
no subsets, you must make it small. 



The APSE provides the mechanism for putting subsets into 
effect from a programming standpoint even if no "incomplete** 
versions of the Ada compiler are allowed, 
b. Structure Manipulation 

Those who perform any amount of word processing 
are familiar with the concepts of deleting and inserting 
words, sentences, and paragraphs. Word processors are 
organized around these structures because they are such an 
intimate part of written prose in most western languages- 
It seems clear, then, that software engineering environments 
should provide programmers with the capability to manipulate 
structures common to software development. An example of 
this is the Cornell Program Synthesizer which provides for 
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direct manipulation o-f structural elements in the PL/I 
subset i t^de-f ines. "While** loops, ** If -Then_El se** blocks, 
expressions, etc., can be inserted or deleted as complete 
entities. Furthermore, the cursor movements are keyed to 
such structural elements rather than the textual elements of 
lines and characters. This illustrates the 

Structure Man 2 pul at ion Princi pi e 
The user of a software engineering environment should be 
able to create, reference, locate, alter and delete 
structures defined within the environment. He should also 
be able to display meaningful representat i ons of them 
within the context of any applicable type or level of 
abstraction. 

Note that although our examples apply to actual ** source 
code** generation, this principle applies to other activities 
as well. For example, the programmer might wish to inter- 
rupt his programming and view some part of the design docu- 
mentation or consult the subroutine **1 ibrar i an'* to see if a 
needed function has already been implemented, 
c. Analysis Support 

During the construction of a program or module, 
the programmer will need to perform various analyses to 
check his work, locate bugs, and ensure conformance with 
standards and policies of his immediate supervisor. There 
are two types of analysis - static and dynamic. 



63 



In static analysis, the programmer checks the 
static structure of the program for various attributes. For 
example, he might check a FORTRAN subroutine to ensure that 
certain formal parameters did not appear on the left of an 
assignment operator if the design called for them to be used 
for input only (like in parameters in Ada) or check an 
entire program to ensure that no coercions are present. In 
Pascal, he might want to ensure that a certain global vari- 
able was referenced only in certain procedures. These exam- 
ples lead us to the 

Static /Analysis Principle 

A software engineering environment should (1) allow the 
user to make assertions about the static structure of a 
module, program, or system of programs and then report 
back to the user which assertions are not valid and why, 
and (2) allow the user to request certain information 
about the static structure and then report this informa- 
tion back to the user in a lucid format. 

For example, if a user asserted that the actual parameters 
used in calling a particular procedure never contained named 
or literal constants, the environment should be able to 
check for conformance with this assertion and, if exceptions 
were found, provide the user with a list of where the 
offending procedure references were located. It should also 
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be able to display these in any applicable context, high- 
lighting in some way the offending parameters themselves. 

The Static Analysis principle is very similar to 
the Enf orcement /Ai d principle in many respects- The main 
difference is that the Enf or cement /Ai d principle is more 
concerned with general rules which all software generated by 
an organization must obey- The Static Analysis principle 
addresses features and character isti cs peculiar to the spe- 
cific program under development which is why the programmer 
himself needs the ability to make assertions and have them 
checked. Quality assurance persons can also use static 
analysis to provide defense in depth (see principle 3 in 
Appendix A) . 

The purpose of dynamic analysis is to study 
program behavior. In order to be complete, a set of design 
documentation must contain acceptance criteria. Some of 
these may be static, others dynamic. When we speak of 
•‘testing** and ‘‘correctness** regarding software, we are 
usually thinking of the program's behavior- We may need to 
know if a certain set of inputs produces the expected out- 
puts, if procedures are called in the expected sequence, the 
frequency distribution of procedure calls for a typical 
input stream, actual execution times, or similar facts con- 
cerning the program's behavior. To support this need, we 
state the following principle: 
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Dynamic f^nalysis Principle 

A software engineering environment should (1) allow the 
user to make assertions about the dynamic structure of a 
module, program, or system of programs and then report 
back to the user which assertions are not valid and why, 
and (2) allow the user to request certain information 
about the dynamic structure and then report this informa- 
tion back to the user in a lucid format. 

These last three principles strongly suggest that a 
software engineering environment should provide many of the 
same types of support we normally associate with database 
and/or artificial intelligence applications. Certainly 
database and artificial intelligence techniques should be 
considered in the design of any software engineering 
environment . 

C. CONCLUSIONS 

We have seen that before we can design an environment to 
support a software engineering methodology, we must first 
define that methodology. We have also seen that design 
documentation is just as essential to software engineering 
as it is to the other engineering disciplines although no 
system of design documentation presently exists that has all 
the fundamental char acter i st i cs of those associated with the 
more mature disciplines. The idea that software developers 
seem to have been so busy building systems to increase the 
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productivity ot others that they haven't yet performed that 
service for themselves has been observed. Finally, we saw 
indications that during design and implementation a signifi- 
cant "knowledge base" is built up and that the techniques of 
database management and artificial intelligence might be 
brought to bear in a productive manner. 
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V. MANAGERIAL ISSUES 



If the design and implementation of reliable, effective 
software are not well understood, then the management of 
projects which have such responsibilities must be a total 
mystery. In CRef- 31, Tonies observes. 

If management science is immature, then we can expect 
software management science to be especially immature, 
since the software industry is itself so new and is 
expanding so quickly. The probability, then, of finding 
effective software management would seem to be small. It 
i s. 

We cannot hope to treat this immensely important topic 
adequately here. However, we will point out some issues 
which could be addressed by a software engineering environ- 
ment. In particular we will look briefly at the planning 
and control functions of management. 

In CRef. 271, Thayer, Pyster and Wood report the results 
of a survey of "... experienced and knowledgeable data 
processing managers as well as some of the leading computer 
scientists from industry, government, and universities with- 
in the US and abroad." In this survey, "...participants 
were asked to express their opinions concerning 20 hypothe- 
sized major issues or problems of SEPM. " SEPM is an ab- 
breviation for Software Engineering Project Management. The 
20 hypothesized problems are reproduced in Appendix D. 
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Eight of the ten hypothetical planning issues, three of the 
six control issues, organizational accountability, and the 
staffing of the project manager position were all considered 
definite problems. None of the 20 issues could be elimi- 
nated as a unimportant. 

A. PLANNING 

Planning requires estimation and estimation presupposes 
the existence of some system of measurement. So far, 
researchers have had a very difficult time in their attempts 
to develop meaningful measurements of software. In CRef. 
283, a number of papers on software metrics have been col- 
lected. In their preface, Perl is, Sayward and Shaw note 
that, **No matter what aspect of software one studies, there 
is a noticeable lack of collected and categoried ^ield data 
on which to build." They continue, "... past software 
projects have rarely integrated data collection into their 
production schedule ..." When this is combined with 
DeMarco's assertion in CRef. 293 that software managers are 
such poor estimators because they don't collect data on 
project performance and compare it with the actual results 
in even the most trivial manner so they can learn from their 
mistakes, we see that the need for data collection is a 
universal one. Ironically, there are few situations where 
large-scale data collection would be easier than in a soft- 
ware development project, where most of the work is done on 
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one or a few computers. Even if we don’t have a well estab- 
lished set of metrics, almost any data collected would be 
useful to the collecting organization in making future esti- 
mates as well as being more grist for the research mill. We 
don’t have space here to discuss exactly what kinds of 
project data might be collected but we can state the fol- 
lowing principle; 



Data Collection Principle 

A software engineering environment should provide for the 
unobtrusive collection of software management data. 

In addition to the collection of general management 
data, one specific class of data should be collected for 
each software product developed. Enough data should be 
collected to establish a complete set of audit trails. It 
should be possible to follow, after the fact, a software 
development project from beginning to end through its 
residual documentation. For example, an "auditor" should be 
able to find the alternative designs considered and the 
rationale used for choosing the one that was actually used. 
He should be able to find out who made a major design deci- 
sion, who implemented a particular module, who tested and 
accepted it, the test specifications and actual test re- 
sults, the costs of these activities, and other such useful 
information. Such things are not only useful for general 
planning purposes, they are also valuable to those who may 
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be tasked with designing enhancements or alterations to a 
particular system and they are essential to any system o^ 
configuration management. We state the following principle: 

fiadit Trail Principle 

A software engineering environment should maintain audit 
trails showing the relationships between specifications, 
designs, implementations, maintenance and enhancements, 
and the resources expended in these activities. Further, 
such audit trails should be navigable in both directions 
from any point. 

Another service which the environment should provide is 
that of librarian. Software engineering efforts are 
notorious for "reinventing the wheel," that is, failing to 
effectively use the knowledge gained from or output of 
previous efforts. If the results of earlier work were 
organized and cataloged, managers could find at least some 
data to guide their estimates. Technical personnel could 
likewise locate and study designs or implementations which 
might be applicable to the problem at hand. It is often 
more efficient to use or combine existing products or 
designs than to create a totally new product. We therefore 
state the following: 
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1 n forma t ion 0 rgan i zat i on Pri nc i pi e 
The information gleaned from the various documentation and 
data collection efforts should be organized for easy 
reference and maintenance. 

B. CONTROL 

Chapter 1 of CRef. 291 begins with the statement, "'You 
can't control >that you can" t measure^'" We submit that it is 
even more difficult to control what you can't even see. 
Many software managers must feel like the fabled emperor who 
wanted some new clothes. When they ask for software project 
progress reports, the one thing they rarely see is the 
software or its design. The control issue is the main 
reason why design documentation is so important to 
management . 

We saw earlier how the Enforcement /Ai d principle applied 
to designers and implementors. Recall that this principle 
involved ensuring "conf or mance with management policies.*' 
In order to carry out this function, the following principle 
should be applied: 



Management Control Principle 

A software engineering environment must be controllable by 
the management of the organization it serves. 
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C. ORGANIZATION 

Organizational structures are developed so that a varie- 
ty oi persons with expertise in a variety of needed disci- 
plines or specialties can work together effectively and 
efficiently to achieve a common goal. The computer support 
for an or gan i z at i onal structure should reflect that struc- 
ture- This leads to the 

Organ 2 zat 2 onal Stractara Princi pi e 
A software engineering environment should be part i t i onabl e 
along the structural lines of the organization so that 
individuals and groups may have the necessary levels of 
privacy and isolation from other individuals and groups, 
and so the communications among them may be reasonably 
controlled by forcing them through established interfaces. 
However, it should also be possible to allow information 
to flow across organizational boundaries, when needed, 
through specially designated and controlled interfaces. 

This is really an application of the Information Hiding and 
Manifest Interface principles (numbers 4 and 7 respectively 
in Appendix A) and the Management Control principle (above) 
to human organizational structures. 

D. CONCLUSIONS 

In this brief chapter we have tried to emphasize the 
importance of management to software engineering, but 
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without del/ing into the various details and styles of 
management. The principles we have outlined are very broad 
and deal only with automated support of management func- 
tions. No doubt anv practicing software manager could think 
of a host of additional features and tools he would like to 
see in a so-Ftware engineering environment. The one concept 
that should be clear at this point is that designers of 
software engineering environments should not be satisfied 
with supporting only the technical personnel. The solving 
of management problems is just as important to the goal of 
increased so-ftware productivity as the solution oT technical 
problems. However, software management problems are much 
more dif-ficult to solve and are often not regarded as being 
within the realm of "computer science." 
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VI. ERGONOMIC ISSUES 



A. INTRODUCTION 

So Tar we have looked at some o*f the engineering and 
managerial issues involved in software engineering environ- 
ment design. We will now look at some ergonomic issues. 
That is, we want to examine the interface between the human 
user and the automated environment in which he will (we 
hope) immerse himself- 

Many o*f the principles stated up to this point have 
ergonomic overtones and some, like the Structure 
Manipulation principle, could even stand as ergonomic 
principles alone. We wish to continue with a list oT 
principles which apply to the design of an/ interactive 
application- Before going on, however, we wish to take time 
to emphasize the need for good ergonomic features. 

The first and foremost reason for good ergonomics is 
that tools which are difficult or awkward to use will be 
ignored- A similar fate awaits tools which are unpredict- 
able or unresponsive- To employ a greatly overworked 
phrase, the tools must be "user friendly." The second 
reason is that the investment required to bring an 
"unfriendly" tool on-line is probably not much less than 
that required for a similar "friendly" tool. We shouldn't 
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waste money on tools that will be discarded. A third reason 
is productivity. Even if designers and programmers must 
work with the given tools because no others are available, 
they will be much more productive with “friendly" tools. 

We have been speaking here of "tools" as if we were 
going to supply them in a "toolkit." We actually wish to 
avoid such a concept. Obviously a software engineering 
environment must put tools (capabilities) into the hands of 
its users. However, it will not do to have a toolkit of 
miscellaneous devices, however useful, that do not work 
together in harmony. This makes the environment as a whole 
"unfriendly." Nevertheless, this is how most of the present 
environments have come about. (Smalltalk is a notable ex- 
ception.) To quote Spier et al . CRef. 303, "Generally, 
tools sprang into spontaneous existence as desperate pro- 
grammers resorted to i mprovi sat i on ; such improvisations are 
colloquially termed 'midnight projects’." This is certainly 
how the tools of UNIX originated although it is claimed by 
Kernighan and Mashey CRef. 313 that the system was built up 
by evolutionary means (survival of the fittest tools) which 
achieved a reasonable degree of integration. Nevertheless, 
they also note in CRef. 313 that things could be better in 
this regard. 

In CRef. 323, Hansen lists a number of principles for 
the design of interactive systems. We will examine these 
briefly in the sections that follow and add a few as well. 
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B- USER ENGINEERING PRINCIPLES 



The user will need to communicate with the environment 
via some "language o-f interaction." It is clear that such a 
language should be designed in accordance with the 
principles of language design formulated in CRef. 51 and 
reproduced here as Appendix A. This leads to our first 
pr i nci pie: 

Interface Language Design Princi pie 
The language of interaction between a user and an 
interactive application should be designed according to 
the principles of good programming language design. 

The first principle listed in CRef. 321 is "Know the 
User". This principle is seen as having two parts. First, 
Hansen suggests building, "... a profile of the intended 
user: his education, experience, interest, how much time he 

has, his manual dexterity, the special requirements of his 
problem, his reaction to the behavior of the system, his 
patience." Second, and more important, is the need for the 
designer to appreciate two traits common among humans: "... 

they forget and they make mistakes. " 

While the second assertion is well beyond dispute, the 
need for a detailed user profile is highly questionable. In 
the first place, humans are highly variable beings and in 
the second place, most of the characteristics listed above 
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change over time. Therefore, rather than having the 
designer tailor the system to a particular type of user, he 
should, at most, discriminate only among broad classes of 
users, e-g. pr of essi onal s vs. amateurs. In any case, he 
should make the system flexible enough to allow users to 
"customize" the interface to their own liking- The old 
engineering adage, "If you can’t make it right, make it 
ad j ustabl e" appl i es. 

In the sections that follow, we will follow Hansen's 
outline and comment on his principles. 

^ !!!§(D9Ci?.§ti90^ 

The first principle listed in this category is that 
of "Selection Not Entry." Here, Hansen recommends selecting 
items from menus via keyboard codes. While this certainly 
has advantages for novice users, menus can quickly become 
frustrating for experts. The word processor on which this 
document was produced provided multiple levels of inter- 
action. First, it allowed selection of a "help level" to 
determine how much command information was displayed con- 
tinuously, Second, for multi-stroke commands, rapid typing 
of the keystrokes resulted in immediate execution of the 
commands while a delay following the first keystroke caused 
a menu of second-stroke commands to be displayed. In other 
words, it minimized the level of required meij^orization while 
allowing the user to take advantage of the increasing level 
of expertise he gained naturally through experience. In 
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CRef. 303, Spier et al . recommend, ‘*at least two modes of 
interface: 'novice' mode and 'expert' mode: preferably 
more." This leads to the 

Mai ti- 1 si'bI Help Principle 

For any interactive tool, there should be a hierarchy of 
"help" levels ranging from no prompts at all to on-line 
instruction. Furthermore, within an environment, the user 
should be able to set the "help level" on a tool -by-tool 
basis (fine granularity of help levels). 

As an example, suppose a user wanted to use a PL/ I 
"while" loop in a program. He could first ask for a tem- 
plate. The system might then want to know which form of the 
"while" loop was desired and display a list of short but 
descriptive names. If this wasn't enough, the user could 
ask to have the alternative templates themselves displayed 
and if he still couldn't make up his mind, he could ask for 
detailed instruction on the char acter i st i cs and typical uses 
of the different types of "while" loops. Such a system 
would provide for all levels of expertise while penalizing 
no one. (Note the i ncorpor at i on of the Localized Cost 
principle of CRef. 53 here.) 

The second principle in this category is that of 
using "Names Not Numbers". This is almost identical to the 
Labeling principle of CRef. 53. Hansen does, however, pro- 
vide the additional recommendation that a dictionary of 
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names (labels) be maintained by the environment on-line so 
they can be easily referenced to refresh the user ^ s memory. 

The third principle is that of ‘‘Predictable Behav- 
ior*'. Although Hansen provides no precise definition, his 
concerns appear to fall mainly within the realm of the 
Regularity, Simplicity and Syntactic Consistency principles 
of CRef. 51- Certainly, unpredictable behavior cannot be 
tolerated since a user would quickly become frustrated. 

The last principle listed by Hansen in this category 
is that of "Access To System Information." Here, he seems 
to be discussing the need for a user to have at least par- 
tial control over his interface with the environment. This 
need is captured in the following principle: 

Configarabil ity Princi pi e 

The user should be able to configure his interface to the 
environment (tool) within the constraints mandated by 
higher management. This capability should display a fine 
granul ar i ty- 

For example, in order to support the organizational 
goals of a software development organization, the various 
levels of management must be able to reserve the alteration 
of environmental features according to organizational poli- 
cies. Those features not reserved to management should be 
accessible to the end user so that he may tailor the 
remainder of the environment to his own liking- One example 
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of such "tailoring" was given earlier in connection with 
setting "help" levels. 

2- "QEtilDize 

The first of Hansen’s principles in this category 
is, "Rapid Execution Of Common Operations." Efficient exe- 
cution of frequently used commands is needed to reduce user 
frustration and make effective use of system resources. 
Less frequently used functions or ones that involve so much 
work they cannot be made to appear instantaneous will take 
longer but should, nevertheless, give the user some positive 
feedback while they are in progress. We capture these ideas 
in the following three related principles: 

M&aningfal Response Principle 

The appearance of the display and the text of messages in 
response to user actions must be appropriate to those 
act i ons. 



Rapid Response Principle 

Simple and frequently used functions should have an 
immediate (in terms of human reflexes) effect upon the 
display. 

Status Reporting Principle 

Lengthy functions should periodically update the display 
to assure the user that progress is being made in carrying 
out the requested function. 
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The second principle given by Hansen in this category 
involves “Display Inertia". It mav be stated as follows: 

Bisplay Inertia Principle 

The display should change by the least amount possible in 
response to a user action. The display should not, how- 
ever, violate the Meaningful Response principle. 

The third of his principles involves what Hansen 
calls "Muscle Memory". He notes that repetitive operations 
like typing are relegated to the lower part o-f the brain and 
there-fore different tools should use similar keystrokes to 
perform similar functions. For example, the "escape" key 
should not be used as an "emergency exit" to return one tool 
to some "base state" while another tool in the same environ- 
ment uses the "escape" character as a special kind of de- 
limiter- This author, like anyone else who has used a 
variety of similar interactive tools (e.g. text editors) on 
a variety of systems, has found the lack of standardization 
of commands and key assignments to be extremely frustrating 
when the same small number of basic functions are being 
perf ormed - 

Another important aspect mentioned by Hansen is 
"burst mode input." He notes that interactive users tend to 
type in short bursts sometimes exceeding 100 words per 
minute- While it is not essential that the system be able 
to respond to commands at this rate, it is essential that it 
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be able to reliably accept both commands and data at what- 
ever rate they are being typed- 

The last principle Hansen mentions in this section 
involves being prepared to "Reorganize Command Par ameter s . 
His main concern here is in being able to adjust the user 
interface to reflect the lessons learned through actual 
experience. The most powerful way to do this is to put the 
necessary adjustments in the hands of the user himself. We 
have already mentioned the Configurability principle in this 
regard. Since we can^t possibly expect to anticipate all of 
a user ^ s needs, we should also seek to make the environment 
extendable^ within certain constraints. That is, we should 
give the user the opportunity to create and use some of his 
own "private tools" CRef. 30D and commands. For example, 
some operating systems have "command files" where commonly 
used command sequences can be placed by a user and invoked 
as a single command. We state the following principle: 

Extens ibi I ity Princi pi e 

An environment should be extensible in the sense that it 
must be possible to add tools at any time and at any level 
which enjoy the same level of control and integration as 
the original tools. 

The combined effects of configurability and extensibility 
effectively remove the need for the detailed user profiles 
mentioned earl ier . 
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As noted earlier, humans are error prone. Hansen’s 
first principle in this section is the provision of "Good 
Error Messages." We consider this as being included in the 
Meaningful Response principle since the correct response to 
an erroneous input is a good error message. 

Hansen’s next principle is worthy of its own place 
in the sun, however. He states it as, "The System Must 
Provide Reversible Actions." We state it as follows: 

Rei/ers ihi 1 ity Princi pi e 

Any action taken by a user must be reversible for some 
period of time or number of subsequent actions. 

Reversibility is one of the most important ergonomic 
principles. Because humans are so error-prone, they tend to 
take actions which they later need to reverse or "undo." No 
one would expect a user to be happy if, after spending 30 
minutes composing a paragraph, he then struck the "delete 
paragraph" key when he meant to strike the "delete word" key 
and found he could not recover from his error except by 
retyping the entire paragraph. 

The Cornell Program Synthesizer CRef. 24D carries 
rever si bi 1 i ty one step further - "reverse execution" of a 
program in support of debugging activities. As described in 
[Ref. 243, "... the forward execution interpreter maintains 
a history file of the flow control and the values destroyed 
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by assignments to variables. 



The reverse execution inter- 



preter restores values and updates the screen to give the 
illusion of the program executing backwards.'* 

This category comes from CRef. 30D- There, Spier et 
al . describe the "windows" concept which has come into 
recent popularity through the work on Smalltalk CRef. 331 
and some recent personal computer products (e.g. Apple Com- 
puter’s Lisa and Macintosh systems^ and Microsoft's Windows) 
Windows basically provide a mechanism for easy context 
switching by the user without the i r r etr i evabl e loss of 
previous contexts. As pointed out in CRef. 301, "It should 
be trivial to interrupt an activity, embark upon another 
(which is similarly i nterruptabl e) , and later resume the 
first activity." The ability to display multiple windows 
simultaneously (though some may be partially hidden) gives 
the user interface a fine granularity. 

Spier et al . also advocate the use of high resolu- 
tion color graphics to enhance user perception. Graphics 
have application throughout the software engineering process 
and are often a much more effective communications medium 
than even the most imaginatively formated text. The promi- 
nence of graphical representat i on in the design documenta- 
tion systems of the other, older engineering disciplines is 
no accident. 
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C. CONCLUSIONS 

In the preceeding paragraphs we have tried to stress the 
importance o*f having a well engineered user interface to any 
interactive application. We then listed a number of impor- 
tant principles for the design of user interfaces. The list 
was by no means exhaustive but it did point out a number of 
often overlooked but important issues. The most important 
conclusion to draw is that a tool which is difficult or 
awkward to use will not be used if an alternative exists, 
and will be used inefficiently at best even if there is no 
al ternati ve. 
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VII. 



CONCLUSIONS AND RECONMENDAT IONS 



A. SOFTWARE DEVELOPMENT AS "ENGINEERING*' 

When software is compared with other complex artifacts 
which are "engineered" rather than "crafted" we find many 
more similarities than differences. In spite of this, soft- 
ware development is still more of a craft than an engineer- 
ing discipline. Although this situation may be understand- 
able given software engineering's youth, it is nonetheless 
important to speed its maturation as much as possible. 

The similarities software artifacts share with other 
products of an engineering development process include a 
high degree of complexity, a requirement for a reasonably 
long useful life of continuous, reliable operation, the need 
for alteration, enhancement and, in a sense, "repair" during 
its life, a requirement that it be serviceable by people not 
intimately involved with its original development, and a 
requirement that it be operable by persons who are ignorant 
of its internal structure and operation. While software has 
no moving parts to wear out, neither, in most cases, to 
solid state electronic circuits. However, like an elec- 
tronic circuit, software may be released with flaws that are 
not immediately apparent and, when these manifest 
themselves, "repair" or replacement is in order. 
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So^t^^are is different from other artifacts in that its 
implementation is not a physical object. This is really the 
only significant difference and its main impact is to 
require that a little extra imagination be used to represent 
software designs- 

As implied by the first paragraph, software engineering 
IS quite different from the methods of the more mature 
engineering disciplines. In fact, it is questionable at 
this time whether a software engineering discipline can be 
said to exist. The most obvious difference seems to be the 
lack of a complete and universal software design documenta- 
tion technology. This failing seems to be at once a symptom 
and a cause of a significant difference in the way engineer- 
ing project resources are employed. In all the older engi- 
neering disciplines, design and implementation are separate 
activities usually carried out by separate groups of people 
who communicate mainly via the design documentation (e.g. 
blueprints). In software "engineering** design and imple- 
mentation are still inseparable activities, and it is for 
this reason that software development remains a "craft." 

Design documentation is also needed to communicate from 
the designer to maintenance personnel, operators and later 
designers a wealth of needed information. Without design 
documentation, the burden of communicating this information 
to all those with a "need to know** would be unmanageable. 
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It IS a strange paradox that Brooks CRef. 



161 decries 



“flowcharting as a "space hogging exercise in drafting" ..^hila 
at the same time observing that adding people to a late 
software project only serves to make it later because the 
communications burden of bringing the new people "up to 
speed" exceeds the amount of useful work they can do. This 
is not to say that flowcharting is an adequate means of 
documenting a software design. Rather, it serves to point 
out the reluctance of software developers to expend the 
considerable effort required to develop any reasonable 
amount of design documentation. This reluctance stands in 
stark contrast to the other engineering disciplines. A 
recent radio commercial announcement for a new model of 
automobile points this out admirably. In the announcement, 
it was claimed that the manufacturer had spent over five 
years and over a billion dollars in design effort on that 
particular model before it went into production. Thus, even 
in such a well established sub-field of engineering as auto- 
motive design, vast amounts of design effort are expended 
routinely, and much of this is spent developing the neces- 
sary design documentation. Software development has no 
analogy in this regard and until it does it cannot truly be 
called "engineering. " 
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B, SOFTWARE ENGINEERING ENVIRONMENTS 



We can increase the rate o-f maturation from software 
development as a craft to software development as an engi- 
neering discipline by designing (with whatever design tools 
we have at hand), developing and implementing software engi- 
neering environments that support an analog of the general 
engineering process as adapted to software development- The 
knowledge gained from this work will suggest many more 
improvements in the way we produce software, while at the 
same time improving software productivity in general by 
making many useful tools available. So far, the reluctance 
of the software industry to engage in this activity seems 
paradox i cal . 

While basic research on programming languages in general 
should continue, there is probably no need for further 
efforts with respect to imperative languages. This is be- 
cause we can effectively control, through the environment, 
most of the language's char acter i st i cs which are apparent to 
the programmer- If increases in productivity and quality 
are truly our goals, then, at this point, the most naive 
efforts at software engineering environment design probably 
hold more promise, in the short term, than the most sophis- 
ticated research on programming language design. 
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C. FUTURE WORK 

Clearly the most critical area for future efforts is in 
the area of software design documentation. Design and its 
associated documentation techniques are crucial to the 
operation of all engineering processes. Unfortunately, the 
needed research probably doesn^’t hold much glory for the 
academician. Certainly the design documentation systems of 
engineering in general were not the result of such research 
(although some may have been by-products of academic inqui- 
ries), but evolved more or less naturally over a long period 
of time. This will eventually occur with software as well. 
The problem is that many do not believe we can afford the 
luxury of such "natural evolution" in the face of what they 
term the "software crisis." 

In particular, we need to find more ways of employing 
graphics in software design documentation. Pictures can 
often communicate more information in less space. They also 
tend to be more universally understood than textual or 
spoken languages. Furthermore, graphics display devices and 
a reasonable amount of general purpose software to support 
them has fallen into the realm of affordability. This means 
that much of the "drafting" burden can be automated. In 
fact, there is already a trend in the more established 
engineering disciplines toward "computer aided drafting." 

Another area requiring further research is software 
management. Software management is in an even more immature 
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state than so-ftware engineering in general. 



So -far we don’t 



^ now how to estimate the cost, time, or complexity of devel- 
oping a piece of software. Furthermore, we don’t know how 
to measure the result of a project for a meaningful compari- 
son with the original (probably meaningless) estimates and, 
worse than that, we usually don’t even try. At least a well 
designed software engineering environment would allow for 
the collection of project data which, when analyzed, might 
yield some insight into the management problem. 

D. CONCLUSIONS 

Software engineering is still very immature as an engi- 
neering discipline. Before significant further maturation 
can take place, work must begin on establishing a design 
documentation system that shares the essential characteris- 
tics of other engineering design documentation systems. 
Software engineering environments with a well integrated set 
of useful tools for aiding design, implementation, quality 
assurance, maintenance and enhancement, and management of 
software hold much more promise for increased software pro- 
ductivity and quality than the traditional approach which 
has restricted itself to programming language design. 
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APPENDIX A 



9f [=§Q9y§39 59ll9D 

(After NacLennan LRef- 5!3) 



1. Abstract 20Dl Avoid requiring something to be stated 
more than once; factor cut the recurring pattern. 

2. Automat ionl Automate mechanical, tedious, or error- 
prone activities. 

3. Defense- in-BepthZ Have a series of defenses so that if 
an error isn't caught by one, it will probably be caught 
by another. 

4. Information Hiding: The language should permit modules 

designed so that (1) the user has all of the information 
needed to use the module correctly, and nothing more; 
(2) the implementor has all of the information needed to 
implement the module correctly, and nothing more. 

5- Labeling: Avoid arbitrary sequences more than a few 

items long; do not require the user to know the absolute 
position of an item in a list. Instead, associate a 
meaningful label with each item and allow the items to 
occur in any order. 

6. Localized Cost: Users should only pay for what they 

use; avoid distributed costs. 

7. Manifest Interface: All interfaces should be apparent 

(manifest) in the syntax. 

8. Orthogonal it y: Independent functions should be control- 

led by independent mechanisms. 

9- Portability: Avoid features or facilities that are 

dependent on a particular machine or a small class of 
machines. 

10. Presentation of Information: The language should allow 

the r epr esentat i on of information that the user might 
know and that the compiler might need. 
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11. Regal <^r 2 t y: Regular rules, without e;< cept i ons, 

easier to learn, use, describe, and implement- 

12, Security: No program that violates the definition of 

the language, or its own intended structure, should 
escape detect! on . 

13, Sij)pl2C2ty: A language should be as simple as possible- 

There should be a minimum number of concepts with simple 
rules for their combination- 

14. Structure: The static structure of the program should 

correspond in a simple way with the dynamic structure 
of the cor r espond i ng computations, 

15- Syntactic Consistency: Similar things should look simi- 

lar; different things different- 
ia, Zero-One- In f ini ty: The only reasonable numbers are 

zero, one, and infinity- 
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APPENDIX B 



(A-fter Rie-fer CRef. 131) 



Principle 1' The Precedence Principle, Planning logically 
takes precedence over all other managerial functions. 

Principle 2z The Effecti^*e Planning Principle. Plans will 
be effective if they are consistent with the organi zat i on s 
policy and strategy framework. 

Princi pi e J5 The Lii'ing Document Principle. Plans must be 
maintained as living documents or they quickly lose their 
value. Plans serve as the foundation for control. When 
they are not updated, control is severely impeded. 

Principle 4- The Early Assignment Principle. Make one 
person responsible for software as early in the life of the 
project as possible. Ensure that he or she occupies a high 
enough position within the hierarchy to successfully compete 
for resources (dollars, people, etc.). Make this person 
accountable for the final results. 



Princi pie 5: The Interface Principle. The efficiency of an 
organization is inversely propor t i onate to the number of 
interfaces it has to maintain during the performance of a 
j ob - 



Principle 6“ The Parity Principle. A software manager's 
responsibility for action should be no greater than that 
implied by the authority delegated to him. 



Principle 7* The Quality Principle. Using a few experi- 
enced people for critical tasks (such as design) is often 
more effective than using larger, unskilled teams. An 
experienced software engineer is **worth his weight in gold.** 



Principle Si The Personnel Development Principle. An open 
commitment to personnel development often pays dividends- 
Better trained technical and managerial personnel can ef- 
fectively cope with tomorrow's problems instead of today's. 
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Principle 9: The Dual Ladder Principle, Promotion should 
be possible up either a technical or a managerial career 
path . 

Principle 10t The Moti’.^ation Principle, Interesting work 
and the opportunity for growth and advancement will motivate 
people to achieve high pr oduc t i vi t y . McGregor's Theory Y 
holds - the individual will rise to the challenge of his 
capab i 1 i t i es. 

Principle 11“ The Leadership Principle, People will follow 
those who represent a means of satisfying their own personal 
goals. Success will come to those who ensure that personal 
goals are compatible with those of the organization. 

Principle 22* The Communications Principle, Productivity 
is a function of the communications burden- As the burden 
increases;, productivity decreases. In other words, the less 
communication required, the higher the productivity. 

Principle 13- The Significance Principle, Controls should 
be implemented to alert managers promptly to significant 
deviations from plans. 

Principle 14i The Measurement Principle, Effective control 
requires that we measure progress against objective, ac- 
curate, and meaningful standards. 

Principle 15- The Exception Principle, The efficient 
manager will concentrate his control efforts on exceptions. 

Principle 16i The Technology Risk Principle, Technology 
should be used only when the risk associated with it is 
acceptabl e. 

Principle 17 1 The Impro^'ement Principle, The manager who 
insists on doing things the wav they have always been done 
will fail. New approaches must be used to meet new chal- 
lenges- Your competition will not allow you to remain 
conservative in the extreme. 

Principle IS- The Peter Principle of Softi^are Management, 
Managers rise to their level of incompetence and are then 
transferred to head a software development project. 
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APPENDIX C 



(After Wasserman CRef. 143) 



1. The methodology should cover the entire software devel- 
opment cycle- 

2. The methodology should facilitate transitions between 
phases of the development cycle. 

3. The methodology must support determination of system 

correctness throughout the development cycle. 

4. The methodology must support the software development 

organi zat i on . 

5. The methodology must be repeatable for a large class of 
sof tware projects. 

6. The methodology must be teachable. 

7. The methodology must be supported by automated tools 

that improve the productivity of both the individual 
developer and the development team. 

8. The methodology should support the eventual evolution of 
the system. 
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APPENDIX D 



(A-fter Thayer, Pyster, and ’/Jood CRef, 273) 



Pl^ann^ng 

1- Reqai reaentsi Requirement speci t i cat i ons are 
frequently incomplete, ambiguous, inconsistent and/or 
unmeasurabl e- 

2, Success^ Success criteria for a software develop- 
ment are frequently i nappropr i ate, which result in "poor- 
quality" delivered software; i.e., not mai ntai nabl e, un- 
reliable, difficult to use, relatively undocumented, etc, 

3- Project: Planning for software engineering projects 
is generally poor. 

4. Cost: The ability to estimate accurately the re- 
sources required to accomplish a software development is 
poor . 

5. Schedule: The ability to estimate accurately the 
delivery time on a software development is poor. 

6. Design: Decision rules for use in selecting the 
correct software design techniques, equipment, and aids to 
be used in designing software in a software engineering 
project are not available. 

7. Test: Decision rules for use in selecting the 
correct procedures, strategies, and tools to be used in 
testing software developed in a software engineering project 
are not available. 

a. Maintainability: Procedures, techniques, and strat- 
egies for designing maintainable software are not available. 

9. Narranty: Methods to guarantee or warranty that the 
delivered software will "work" for the user are not 
avai 1 abl e. 

10. Control: Procedures, methods, and techniques for 
designing a project control system that will enable project 
managers to successfully control their project are not 
r eadi 1 y avai 1 abl e- 
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11. Typ&i Decision rules for selecting the proper 
organ! zat i onal structure; e.g., project, matrix, function, 
are not available. 



12- f)ccoantabi 1 it\/i The accountability structure in 
many software engineering projects is poor, leaving some 
question as to who is responsible for various project 
f unct i ons. 



Staffing 

13. Project Manager' Procedures and techniques for the 
selection of project managers are poor. 



Dfr ectfng 

14. Techniques^ Decision rules for use in selecting 
the correct management techniques for software engineering 
project management are not available. 



Contrgiiing 

15. Visibility' Procedures, techniques, strategies, 
and aids that will provide visibility of progress (not just 
resources used) to the project manager are not available. 

16. Reliability'^ Measurements or indexes of reliabil- 
ity that can be used as an element of software design are 
not available and there is no way to predict software fail- 
ure; i.e., there is no practical way to show the delivered 
software meets a given reliability criteria. 

17. Maintainability* Measurements or indexes of main- 
tainability that can be used as an element of software 
design are not available; i.e., there is no practical way to 
show that a given program is more maintainable than another. 

18. Goodness • Measurements or indexes of "goodness’* of 
code that can be uses as an element of software design are 
not available; i.e., there is no practical way to show that 
one program is better than another. 

19. Programmers * Standards and techniques for measur- 
ing the quality of performance and the quantity of produc- 
tion expected from programmers and data processing analysts 
are not available. 
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20. Tracing: Techniques and aids 

acceptable means o-f tracing a software 
requirements to completed code are net gen 



that provide an 
development from 
erally available. 
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APPENDIX E 



Pr^nc^g^es of Software Sngi^neer i_ng Environment Design 



1- Methodology Support! A software engineering environment 
should be designed to support a specific engineering 
methodol ogy . 

2. Design Documentation! A software engineering environ- 
ment should support a design documentation system that 
is (1) complete, (2) capable of representing appropriate 
levels and types of abstractions with fine gr anul ar i ty , 
(3) universal, and (4) economical - 

3. £nf orcement/f)id! A software engineering environment 
should enforce technical correctness and conformance 
with management policies while aiding the user in 
maintaining these standards- 

4. Consistency Principle! "Permanent ** alteration of one 

view of a design should not be "accepted" by the envi- 
ronment until all related views are made to be 

consistent with the change. 

5. Structure Man i pul at ion! The user of a software engi- 
neering environment should be able to create, reference, 
locate, alter, and delete structures defined within the 
environment. He should also be able to display meaning- 
ful r epr esentat i ons of them within the context of any 
applicable type or level of abstraction. 

6. Static ^^nalysis! A software engineering environment 
should (1) allow the user to make assertions about the 
static structure of a module, program, or system of 
programs and then report back to the user which asser- 
tions are not valid and why, and (2) allow the user to 
request certain information about the static structure 
and then report this information back to the user in a 
lucid format. 

7. Dynamic /Analysis! A software engineering environment 
should (1) allow the user to make assertions about the 
dvnamic structure of a module, program, or system of 
programs and then report back to the user which asser- 
tions are not valid and why, and (2) allow the user to 
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request certain information about the dynamic structure 
and then report this information back to the user in a 
lucid format. 

a. D^ta Collection: A software engineering environment 

should provide for the unobtrusive collection of soft- 
ware management data. 

9. f)adit Trail: A software engineering environment shculd 

maintain audit trails showing the relationships between 
specifications, desi gns, i mpl ementat i ons, mai ntenance 
and enhancements, and the resources expended in these 
activities. Further, such audit trails should be 

navigable in both directions from any point. 

10. Information Organization: The information gleaned from 

the various documentation and data collection efforts 
should be organized for easy reference and maintenance. 

11. Management Control: A software engineering environment 

must be controllable by the management of the organiza- 
tion it serves. 

12. Organizational Structure: A software engineering envi- 

ronment should be parti ti onabl e along the structural 
lines of the organization so that individuals and groups 
may have the necessary levels of privacy and isolation 
from other individuals and groups, and so the communica- 
tions among them may be reasonably controlled by forcing 
them through established interfaces. However, it should 
also be possible to allow information to flow across 
organi zat i onal boundaries, when needed, through special- 
ly designated and controlled interfaces. 

13. Interface Language Design: The language of interaction 

between a user and an interactive application should be 
designed according to the principles of good programming 
language design. 

14. Multi-le^el Help: For any interactive tool, there 

should be a hierarchy of "help** levels ranging from no 
prompts at all to on-line instruction. Furthermore, 
within an environment, the user should be able to set 
the "help level** on a tool-by-tool basis (fine granu- 
larity of help levels). 

15. Configurability: The user should be able to configure 

his interface to the environment (tool) within the con- 
straints mandated by higher management. This capability 
should display a fine granularity. 
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16. ^ean ingf al Res ponsel The appearance oi the display and 
the text o-f messages in response to user actions must be 
appropriate to those actions. 

17. Rapid Response: Simple and frequently used functions 

should have an immediate (in terms of human reflexes) 
effect upon the display. 

13. Statas Report ingl Lengthy functions should periodically 
update the display to assure the user that progress is 
being made in carrying out the requested function. 

19. Display Inertial The display should change by the least 
amount possible in response to a user action. The 
displ ay should not, however, violate the Meaningful 
Response principle. 



20. Extensihilityl An environment should be extensible in 
the sense that is must be possible to add tools at anv 
time and at any level which enjoy the same level of 
control and integration as the original tools. 



21. Re%^ersibil ityl Any action taken by a 
reversible for some period of time 
subsequent actions. 



user must 
or number 



be 

of 
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